). In this post, I will present a short intro to MDM, explaining what it is, what it's good for, how you can use MDS to help your organization maintain data quality and integrity while saving money, and of course - How you can reap rewards and set up your Facebook group named "Yes, I too manage an MDM project, but I still found time to open a Facebook group".
What is MDM?The first question we need to answer is what exactly is Master Data (or MD, to be shorter than ever).
The term Master Data applies to the lists of data commonly used by various applications which comprise an entire organizational system - Operational applications, as well as BI systems, analysis tools, reporting mechanisms, etc. In effect, these are tables which describe entities such as customers, products and employees, and which do not describe short transactions (orders, sales, production). These entities change over time and are referred to as slowly changing entities.
When we have only one application (CRM, for example), we need to update the customer data so that they correctly represent real-world conditions (for example, a customer changing his address), and see that we don't have double and redundant customers registered in the system, that first names are entered in the first name field and surnames are entered in the surname field, that addresses are entered in a unified format, and that customer managers take the time to enter zip code numbers.
The issue becomes much more complex when we have several systems between which we need to synchronize the data. Maintaining the cliché of "one single truth" in the organization becomes difficult and complicated - and let's be truthful, who among us hasn't worked endless hours to make reports show the same numbers when viewed from different directions.
If we try to answer the question we posed above, then MDM is actually a series of processes and tools which help define and manage these data lists and maintain the same reliable and valid data. The problems we face which MDM is intended to solve are:
• Decay - the very reality described by the data changes, while the data does not. For example, a customer changing its address.
• Conflict - superfluous data (in part or in full) is entered into the system. Which of the data is the right one? For example, two identical parts manufactured in two different factories receiving different catalog numbers.
• Corruption - when correct and verified data changes in such a manner that it is no longer valid and true. For example, this can happen when someone forgets a decimal point when entering a new price for a product.
• Inconsistency - exactly as it implies. For example, in address formats, in product names, etc.
Ok... I see the need. Why not just develop something like that?
In June of 2007, Microsoft purchased Stratature, which developed one of the leading MDM products. Two years later, Microsoft releases its CTP for MDM. How long do you think it would take you to write something like that?
How does it work?
An MDM project includes the following phases:
1. Identifying the sources for the Master Data (i.e. - for the love of God, in how many databases are my customers' names stored)
2. Identifying the producers and consumers of the Master Data (or how many programs are we using in this organization for orders and invoicing, for warehouse management, etc.)
3. Gathering and analyzing meta-data regarding the Master Data in each of our data sources. What entities are we dealing with, which properties are saved for each entity, what are the entities' property names, which data types are used, what limitations apply to each program, default values, relations and hierarchies and who is responsible for these definitions (you pay for your mistakes, every dog has its day, and so forth).
4. Appointing persons who will be responsible for the Master Data (probably not the same person who will be responsible for both the product MD and the customer MD).
5. Making decisions and implementing a plan for monitoring the Master Data: how is the MD maintained, what it includes, for how long is it stored, how changes to it are authorized, how information regarding such changes is stored.
6. Developing the Master Data module: Mapping the programs accessing the MD, data types, relations, limitations and the relations between the MD and the MD sources identified in phase 1. This is the most difficult and interesting part of the project and it is absolutely worthless if carried out without shouting, shoving, hair-pulling and catfights during the entire phase, between anybody who has ever participated in an "MDM project" meeting.
7. Selecting the tools for building the MD lists, by cleansing and merging the lists from the entire system. Each data type has its own tools, such as Customer Data Integration, and Product Information Management.
8. Designing the infrastructure for managing, storing and supplying the Master Data.
9. Creating and testing the MD.
10. Changing MD producers and consumers so that they communicate with the MDM system when they create or use information.
11. Implementing MD maintenance processes - this is the very core of the MDM project: building processes and tools for maintaining the data validity and integrity.
Where does Microsoft's MDS fit into all this? The main features are as follows:
• A central management tool for MD entities, which provides permission-based access to the data.
• A flexible data module based on meta-data, which can be changed by data administrators.
• A business rule engine for verifying the quality of data entering the system.
• A workflow that notifies data supervisors regarding violations of the preset rules.
• Version management for all entities and hierarchies.
• A flexible permissions module based on Active Directory.
• Integration with other Microsoft systems (Sharepoint, Dynamics, PerformancePoint, Excel), access through Web Services, or through SQL Server Views.
חברת ואלינור
http://www.valinor.co.il
http://www.sqlserver.co.il
LinkedIn - SQLServer Valinor
